0x1 API規格文件

是的，終於來到閱讀文件的這一天了
忘記是什麼時候建立的習慣，拿到一個文件我都會先把目錄看個幾次

• 主要幾個大標是自己會優先去看，能快速建構出架構及開發規劃
  • API 應用場景
  • 連線說明及測試方式
  • 請求 API 前的前置動作

0x2 應用場景

• 文件列出三個，這裡依照有寫過的金流來進行安排
  1. 建立訂單 - 取得虛擬帳號
     1. 訂單成立
     2. 付款方式選擇 虛擬帳號匯款 後結帳
     3. 呼叫 API 「建立訂單交易」，並等待回傳虛擬帳號
     4. 畫面顯示虛擬帳號，等待顧客付款
     5. 等待 API 「即時訊息通知」呼叫本機 API
     6. 使用 API 「訊息查詢服務」解密上一步的訊息
  2. 建立訂單交易 - 信用卡
     1. 訂單成立
     2. 付款方式選擇 虛擬帳號匯款 後結帳
     3. 呼叫 API 「建立訂單交易」，並等待回傳付款頁URL
     4. 畫面跳轉至付款頁，等待顧客付款
     5. 付款頁會依照 API 「建立訂單交易」設定的 returnURL進行跳轉，顯示付款成功與否
  3. 建立訂單交易 - 信用卡 + 3D 驗證
     1. 訂單成立
     2. 付款方式選擇 虛擬帳號匯款 後結帳
     3. 呼叫 API 「建立訂單交易」，並等待回傳付款頁URL
     4. 畫面跳轉至付款頁，等待顧客輸入信用卡卡號後，跳轉到發卡行 3D 驗證
     5. 付款頁會依照 API 「建立訂單交易」設定的 returnURL進行跳轉，顯示付款成功與否
• 個人覺得 信用卡 跟 信用卡 + 3D 驗證 的流程一模一樣，只是 3D 多了發卡行驗證，但都是銀行伺服器驗證，基本上權責不在自己的伺服器。
• 文件裡有 LINE 的付款流程，但 API 服務規格沒有寫，所以就沒有額外提出來了

0x3 連線說明及測試方式

• 最重要的一個，沒有提供就只能靠通靈了，裡面主要提到幾點是開發過程中必須注意的

  1. 協定為 HTTPS (TLS1.2)
  2. Content-Type 為 application/json;charset=utf-8

• 測試網址這裡就沒有貼出來了

• 測試注意事項

  1. 自動交易成功測試-測試建立「虛擬帳號」訂單成功後，系統每隔 5 分鐘會自動模擬付款完成，只要 5 分鐘後確認訂單是否變為「已付款」即可
  2. 自動交易失敗測試-若訂單編號(OrderNo)尾數為 9，系統不會模擬付款，可用於測試「付款帳號逾期」情境。需要訂單編號尾數
  3. 交易查詢測試-透過 API 產生的訂單資料，除了可以透過查詢 API 取得外，還可登入「豐收款商戶管理後台」的測試環境查詢測試資料。
  4. 信用卡一樣有測試的卡號，這裡也不會貼出來
  5. 訊息通知 - 只接受 80/443 (http/https)

0x4 請求 API 前的前置動作

• 金融業對於資料安全，比很多行業都還要高很多，所以流程比較複雜一些。

• 依據「電子銀行業務安全控管作業基準」的要求，主要需求有兩個

  1. 安全簽章 (Sign): 將內文與參數進行 SHA-256 運算雜湊
  2. 內文加密機制 (Message): 採用對稱加密 AES-CBC

• 流程簡述:

  1. 根據銀行提供的商店代碼取得 Nonce
  2. 根據銀行提供的 4 把雜湊值 XOR運算出 Hash Id
  3. 把前兩步的結果，加上內文進行 SHA-256 運算來取得 Sign
  4. 把 Nonce 進行 SHA-256 運算後取得尾端16個文字為 IV
  5. 以 Hash Id 為 key, IV 為 IV 進行 AES-CBC 運算

0x5 今日結語

明天就要開始前置動作 Part 1
終於要開始有 code 出現了，再也不是一堆文字的混篇幅了(喂
對，結語就是這麼簡短，明天見